home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1588 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. Path: geraldo.cc.utexas.edu!usenet
  2. From: Richard Kilgore <rkilgore@lore.ece.utexas.edu>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why use private class members instead of protected?
  5. Date: 11 Jan 1996 19:55:51 GMT
  6. Organization: The University of Texas at Austin, Austin, Texas
  7. Message-ID: <4d3q07$n8o@geraldo.cc.utexas.edu>
  8. References: <30F4AB49.6ABB@sierra.net> <30F50874.15FB7483@intellektik.informatik.th-darmstadt.de>
  9. NNTP-Posting-Host: lore.ece.utexas.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1N (X11; I; Linux 1.3.18 i586)
  14. X-URL: news:30F50874.15FB7483@intellektik.informatik.th-darmstadt.de
  15.  
  16. Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> wrote:
  17. >TGColwell wrote:
  18. >> 
  19. >> I'm relatively new to c++.  I have one quick question:  If child
  20. >> classes can only access protected members of the parent class,
  21. >> why make any members of any class private?  Wouldn't it be
  22. >> better to make members of the parent class protected so that the
  23. >> class is alway "inheritance ready"?
  24. >> 
  25. >
  26. >No,
  27. >it's quite often a better approach to make these data-members private and
  28. >provide the suitable accessor functions. In this way you can change the
  29. >representation of the data-members without the problem that modifications
  30. >will 'propagate' downwards the class-hierachie.
  31. >
  32. >    Enno
  33.  
  34. I'd like to add my 2 cents worth here.  I have on occasion seen the approach
  35. of making a data member private, and then providing an accessor/mutator
  36. combination method like the following:
  37.  
  38.     DataType& MyClass::data() { return _data; }
  39.  
  40. The idea is to provide one function that the user can call to get the data's
  41. value OR to change it.
  42.  
  43. This makes no sense to me.  You have just set yourself up for a pain in the
  44. ass if you ever want to change the internal representation of the data.
  45. For example, suppose you store a fraction as two integers and provide
  46. accessor/mutators like the line above for each of the numerator and 
  47. denominator values.  Then later you want to represent it as a float and
  48. calculate such values on the fly.  Don't know if this is a good exmaple
  49. of a reasonable thing to do, but you get the picture.  Now you're stuck with
  50. an interface that promises you can return a REFERENCE to an integer value.
  51. But how do you return a reference to something that doesn't exist in memory?
  52. One idea is to keep a temporary storage location around for returning such
  53. values: a serious kludge in which the user better not hold onto his own
  54. reference to your return value, because it might change soon.  Another
  55. approach entails allocating memory for the return type and expecting the user
  56. to free it: Yuck!  Inneficient and dangerous.  In either case, a user's
  57. attempt to use this returned value as an Lvalue will have no effect on the
  58. class's data.
  59.  
  60. I realize you might want to return a reference for efficiency's sake, if the
  61. data type being returned is large, but there is no reason not to return a 
  62. CONST reference for this purpose.  Then if you ever change the internal
  63. implementation of the class, you could use the temporary storage location
  64. for return values and not have to worry about cooky side effects.
  65.  
  66.     - rick
  67.  
  68. -- 
  69. Richard B. Kilgore
  70. Grad Student, University of Texas at Austin
  71. WWW URL: http://lore.ece.utexas.edu/~rkilgore/
  72. E-mail rkilgore@lore.ece.utexas.edu
  73.  
  74.